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Questions of belief are essential in analyzing protocols for the authentication of prin- 
cipals in distributed computing systems. In this paper we motivate, set out, and 
exemplify a logic specifically designed for this analysis; we show how various protocols 
differ subtly with respect to the required initial assumptions of the participants and 
their final beliefs. Our formalism has enabled us to isolate and express these differences 
with a precision that was not previously possible. It has drawn attention to features 
of protocols of which we and their authors were previously unaware, and allowed us to 
suggest improvements to the protocols. The reasoning about some protocols has been 
mechanically verified. 

This paper starts with an informal account of the problem, goes on to explain 
the formalism to be used, and gives examples of its application to protocols from the 
literature, both with shared-key cryptography and with public-key cryptography. Some 
of the examples are chosen because of their practical importance, while others serve to 
illustrate subtle points of the logic and to explain how we use it. We discuss extensions 
of the logic motivated by actual practice — for example, in order to account for the use 
of hash functions in signatures. The final sections contain a formal semantics of the 
logic and some conclusions. 
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1. The Problem 



In distributed computing systems and similar networks of computers it is necessary 
to have procedures by which various pairs of principals (people, computers, services) 
satisfy themselves mutually about each other's identity. A common way to approach 
this is by means of secrets, usually encryption keys. In barest outline, an authentication 
protocol guarantees that if the principals really are who they say they are then they will 
end up in possession of one or more shared secrets, or at least they will become able to 
recognize the use of other principals' secrets (see, for example, Needham & Schroeder 
1978). For example, some authentication protocols establish shared encryption keys 
that principals can use in subsequent communication. Other authentication protocols, 
based on public-key cryptography (see, for example, Rivest et al. 1978), first distribute 
the public keys of principals, and then use them to establish shared secrets. 

Protocols involving shared-key cryptography use an authentication server which 
shares a key with each principal and typically generates new session keys for communi- 
cation between the principals. Public-key protocols use a certification authority which 
has a well-known public key and is trusted to pass on the public keys of the principals. 
Both authentication servers and certification authorities are trusted to make proper use 
of the data they hold when executing authentication protocols; authentication servers 
are often also trusted to generate new secrets in a proper manner — for example, not to 
issue the same one every time. 

Authentication would be straightforward in a sufficiently benign environment. 
Such cannot usually be assumed, and it is particularly necessary to take precautions 
against confusion caused by the reissue of old messages. Specifically, one must ensure 
that a replay cannot force the use of an old and possibly compromised secret. A good 
part of the work in the literature is devoted to ensuring that the information upon 
which the protocols act is timely. The style of the precautions taken has caused it 
to be recognized for a long time that we are dealing with questions of belief, trust, 
and delegation; however, this has been recognized only imprecisely rather than in any 
formalism. 

As a result of varied design decisions appropriate to different circumstances, a va- 
riety of authentication protocols exist. Therefore, there is a perceived need to explicate 
them formally to understand to what extent they really achieve the same results. They 
differ subtly in their final states, and sometimes a protocol may be shown to depend on 
assumptions that one might not care to make. We define a logic of authentication in 
order to explain the protocols step by step, with all initial assumptions made explicit 
and with the final states clearly set out. 
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These are examples of the sort of questions we would like to be able to answer 
with the help of formal methods: 

What does this protocol achieve? 

Does this protocol need more assumptions than another one? 

Does this protocol do anything unnecessary that could be left out without 
weakening it? 

Does this protocol encrypt something that could be sent in clear without 
weakening it? 

In later sections, we show how the logic is able to help us answer these questions for a 
number of example protocols. 

It is important to note that certain aspects of authentication protocols have been 
deliberately ignored in our treatment. Since we operate at an abstract level, we do not 
consider errors introduced by concrete implementations of a protocol, such as deadlocks, 
or even inappropriate use of cryptosystems (as in Voydock & Kent 1983). Furthermore, 
while we allow for the possibility of hostile intruders, there is no attempt to deal with 
the authentication of an untrustworthy principal, nor to detect weaknesses of encryption 
schemes or unauthorized release of secrets (as in Dolev & Yao 1983; Millen et al. 1987). 
Rather, our study concentrates on the beliefs of trustworthy parties involved in the 
protocols and on the evolution of these beliefs as a consequence of communication. 
Our experience with authentication protocols has indicated that this kind of study is 
one of the most needed by current protocol designers. 

We focus on fairly standard uses of encryption and secrets. We also discuss some 
variants of practical importance, and how they can be explained logically. Our treat- 
ment includes both shared-key cryptography and public-key cryptography. (Shared-key 
cryptography can be treated in isolation, as in (Burrows et al. 1988); on the other hand, 
a logic for public keys should include one for shared keys: for economic reasons, many 
practical schemes based on public keys use some shared keys.) 

Our goal, however, is not to provide a logic that would explain every authenti- 
cation method, but rather a logic that would explain most of the central concepts in 
authentication. This logic may serve both as a basic tool and for illustrative purposes. 
It is hoped that protocol designers will adapt it to suit their specific needs. 

Before introducing the notation and technical terminology, it may be worth stating 
some of the main principles in the vernacular. They cannot be regarded as precise, of 
course. 
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If you've sent Joe a number that you have never used for this purpose before 
and if you subsequently receive from Joe something that depends on know- 
ing that number, then you ought to believe that Joe's message originated 
recently — in fact, after yours. 

If you believe that only you and Joe know K, then you ought to believe that 
anything you receive encrypted with K as key comes originally from Joe. 

If you believe that K is Joe's public key, then you should believe that any 
message that you can decrypt with K comes originally from Joe. 

If you believe that only you and Joe know X, then you ought to believe that 
any encrypted message you receive containing X comes originally from Joe. 

2. The Formalism 

Authentication protocols are typically described by listing the messages sent between 
the principals, and by symbolically showing the source, the destination, and the con- 
tents of each message. This conventional notation is not convenient for manipulation 
in a logic, since we wish to attach exact meanings to each part of each message and 
these meanings are not always apparent from the data contained in the messages. In 
order to introduce a more useful notation whilst preserving correspondence with the 
original description of the protocols, we transform each message into a logical formula. 
This logical formula is an idealized version of the original message. Then we annotate 
each idealized protocol with assertions, much as in a proof in Hoare logic (Hoare 1969). 
These assertions are expressed in the same notation used to write messages. An asser- 
tion usually describes beliefs held by the principals at the point in the protocol where 
the assertion is inserted. 

In this section, we describe the informal syntax and semantics of our logic, its 
rules of inference, the transformations that we apply to protocols before their formal 
analysis, and the rules to annotate protocols. 

Basic notation 

Our formalism is built on a many-sorted modal logic. In the logic, we distinguish several 
sorts of objects: principals, encryption keys, and formulas (also called statements). We 
identify messages with statements in the logic. Typically, the symbols A, B } and S 
denote specific principals; K a b } K aS} and K\, s denote specific shared keys; K a , Kb, and 
K s denote specific public keys, and A'" 1 , K^ 1 , and Kj 1 denote the corresponding 
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secret keys; N a , iV&, and N c denote specific statements. The symbols P, Q } and R 
range over principals; X and Y range over statements; K ranges over encryption keys. 
All these may be used either as metasymbols (to write schemata) or as free variables 
(with an implicit universal quantification); this minor confusion is essentially harmless. 

The only propositional connective is conjunction, denoted by a comma. Through- 
out, we treat conjunctions as sets and take for granted properties such as associativity 
and commutativity. In addition to conjunction, we use the following constructs: 

P ^ X: P believes X } or P would be entitled to believe X . In particular, the principal 
P may act as though X is true. This construct is central to the logic. 

P < X: P sees X . Someone has sent a message containing X to P, who can read and 
repeat X (possibly after doing some decryption). 

P |~ X: P once said X . The principal P at some time sent a message including the 
statement X . It is not known whether the message was sent long ago or during 
the current run of the protocol, but it is known that P believed X when he 
sent the message. 

P |=> X: P has jurisdiction over X . The principal P is an authority on X and should be 
trusted on this matter. This construct is used when a principal has delegated 
authority over some statement. For example, encryption keys need to be 
generated with some care, and in some protocols certain servers are trusted to 
do this properly. This may be expressed by the assumption that the principals 
believe that the server has jurisdiction over statements about the quality of 
keys. 

$(X): The formula X is fresh, that is, X has not been sent in a message at any time 
before the current run of the protocol. This is usually true for nonces, that 
is, expressions generated for the purpose of being fresh. Nonces commonly 
include a timestamp or a number that is used only once, such as a sequence 
number. 

K 

P ^Q: P and Q may use the shared key K to communicate. The key K is good, in 
that it will never be discovered by any principal except P or Q, or a principal 
trusted by either P or Q. 

K 

i— >P: P has K as a "public key. The matching secret key (the inverse of K, denoted 
A' -1 ) will never be discovered by any principal except P, or a principal trusted 
by P. 

P ^±Q: The formula X is a secret known only to P and Q } and possibly to principals 
trusted by them. Only P and Q may use X to prove their identities to one 
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another. Often, X is fresh as well as secret. An example of a shared secret is 
a password. 

{X}k- This represents the formula X encrypted under the key K. Formally, {X}k 
is an abbreviation for an expression of the form {X}k from P. We make the 
realistic assumption that each principal is able to recognize and ignore his 
own messages; the originator of each message is mentioned for this purpose. 
In the interests of brevity, we typically omit this in our examples. 

(X)y'- This represents X combined with the formula Y; it is intended that Y be a 
secret, and that its presence prove the identity of whoever utters (X) Y - In 
implementations, X is simply concatenated with the password Y ; our notation 
highlights that Y plays a special role, as proof of origin for X . The notation 
is intentionally reminiscent of that for encryption, which also guarantees the 
identity of the source of a message through knowledge of a certain kind of 
secret. 

A more formal treatment of the semantics of these constructs can be found below. 
Here, we simply give and motivate the rules of inference that characterize them. 

Logical postulates 

Some informal preliminaries are useful to understand the rules of inference of our logic. 

In the study of authentication, we are concerned with the distinction between 
two epochs: the past and the present. The present epoch begins at the start of the 
particular run of the protocol under consideration. All messages sent before this time 
are considered to be in the past, and the authentication protocol should be careful 
to prevent any such messages from being accepted as recent. All beliefs held in the 
present are stable for the entirety of the protocol run; furthermore, we assume that 
when principal P says X then he actually believes X . However, beliefs held in the past 
are not necessarily carried forward into the present. The simple division of time into 
past and present suffices for our purposes. 

An encrypted message is represented as a logical statement bound together and 
encrypted with an encryption key. It is assumed that the encryption is done in such 
a way that we know the whole message was sent at once. If two separate encrypted 
sections are included in one message, we treat them as though they arrived in separate 
messages. A message cannot be understood by a principal who does not know the key 
(or, in the case of public-key cryptography, by a principal who does not know the inverse 
of the key); the key cannot be deduced from the encrypted message. Each encrypted 
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message contains sufficient redundancy to allow a principal who decrypts it to verify 
that he has used the right key. In addition, messages contain sufficient information for 
a principal to detect (and ignore) his own messages. 

Now we are ready to discuss the logical postulates. We do not present the postu- 
lates in the most general form possible; our main concern is to have enough machinery 
to carry out some realistic examples and to explain the essence of our method. 

• The message-meaning rules concern the interpretation of messages. Two of the 
three concern the interpretation of encrypted messages, and the third concerns 
the interpretation of messages with secrets. They all explain how to derive beliefs 
about the origin of messages. 

For shared keys, we postulate: 

P^Q^P, P<{X} K 
P^Q^X 

That is, if P believes that the key K is shared with Q and sees a message X 
encrypted under K, then P believes that Q once said X. For this rule to be 
sound, we must guarantee that P did not send X himself; it suffices to recall 
that {X}k stands for a formula of the form {X}k from R } and to require 
that R^P. 

Similarly, for public keys, we postulate: 

P\e&Q, P<{X} k -i 

p^q^x 

For shared secrets, we postulate: 

P^Q^P, P<(X)y 
P^Q^X 

That is, if P believes that the secret Y is shared with Q and sees (X) Y , then 
P believes that Q once said X . This postulate is sound because the rules for 
<, given below, guarantee that (X) Y was not just uttered by P himself. 

In real life the decryption of a message to yield a content says, in and of itself, only 
that the content was produced at some time in the past; we have no idea whether 
it is new or the result of a replay. 

• The nonce-verification rule expresses the check that a message is recent, and hence 
that the sender still believes in it: 
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That is, if P believes that X could have been uttered only recently and that Q 
once said X, then P believes that Q believes X . For the sake of simplicity, X must 
be "cleartext," that is, it should not include any subformula of the form 
(When this restriction is not met, we can conclude only that Q has recently said 
X. We might introduce a "has recently said" operator to express this conclusion, 
should the need arise in an example.) 

This is the only postulate that promotes from |~ to ^. It reflects in an abstract and 
timeless way the practice of protocol designers of using challenges and responses. 
One participant issues a fresh statement as a challenge. Since the challenge has 
been generated recently, any message containing it is accepted as timely and taken 
seriously. In general, challenges need not be encrypted but responses must be. 

The jurisdiction rule states that if P believes that Q has jurisdiction over X then 
P trusts Q on the truth of X: 

P^Q^X, P^Q^X 
P^X 

A necessary property of the belief operator is that P believes a set of statements 
if and only if P believes each individual statement separately. This justifies the 
following rules: 

P^X, P^Y P\b(X,Y) P\eQ\e(X,Y) 
P\b(X,Y) p^x p^Q^x 

Other similar rules could be introduced as required. 
A similar rule applies to the operator |~: 

P^Q^(X,Y) 
P^Q^X 

Note that if P |ee Q f~ X and P |ee Q f~ Y it does not follow that P |ee Q f~ (X, Y), 
since this would imply that the two parts X and Y were uttered at the same time. 

If a principal sees a formula then he also sees its components, provided he knows 
the necessary keys: 

P<(X,Y) P<(X) Y P^Q^P, P<{X} k 



P<X P<X P<X 

P &P, P<{X} k PW&Q, P<{X} k -i 
P«X P«X 
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Recall that {X}k stands for a formula of the form {X}k from R. As a side 
condition, it is required that R ^ P, that is, {X}k is not from P himself. A 
similar statement applies to {X} K -i. 

The first rule in the second line is justified by the implicit assumption that if P 
believes that K is his public key, then P knows the corresponding secret key, A' -1 . 

Note that if P <\ X and P <\ Y it does not follow that P <\ (X, Y), since this would 
imply that X and Y were uttered at the same time. 

• If one part of a formula is known to be fresh, then the entire formula must also be 
fresh: 

Other similar rules can be written, for instance to show that if X is fresh then 
{X}k is fresh; we do not need these rules in our examples. 

• The same key is used between a pair of principals in either direction. We write 
the following two rules to reflect this property: 

P^R^R' P |ee R&R' 
P^R'i^R P |ee R> &R 

• Similarly, a secret can be used between a pair of principals in either direction. We 
write the following two rules to reflect this property: 

P |ee R^R 1 P^Q ^R^R 1 
P^R'^R P |ee Q |ee R> ^R 

Given the postulates, we can construct proofs in the logic. A formula X is provable 
in the logic from a formula Y if there is a sequence of formulas Zo , . . . , Z n where Zo = Y , 
Z n = X } and each Zi+\ can be obtained from previous ones by the application of a 
rule. As usual, this can be generalized to prove schemata. 



On quantifiers in delegations 

Delegation statements typically mention one or more variables. For example, prin- 
cipal A may let the server S generate an arbitrary shared key for A and B. We can 
express this as 

A |ee S\=> A&B 
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Here the key K is universally quantified, and we can make explicit this quantification 
by writing 

A \eVK.(S& A&B) 

For complex delegation statements, it is generally necessary to write quantifiers 
explicitly in order to avoid ambiguities. For example, the reader can verify that the 
two formulas 

A \eVK.(S& B\=> A&B) 
A |ee S&VK.(B& A&B) 

convey different meanings. 

In some of our earlier work on the logic, this need was not recognized, and in fact 
it does not arise in any of the examples treated here (there are no nested jurisdiction 
statements). Therefore, we leave quantifiers implicit in this paper. 

Our formal manipulation of quantifiers is quite straightforward. All we use is the 
ability to instantiate variables in jurisdiction statements, as reflected by the rule 

P \e VV 1 ...V n .(Q&X) 
P^Q'^X 1 

where Q' |=> X' is the result of simultaneously instantiating the variables Vi, . . . , V n in 
Q^X. 

Idealized protocols 

In the literature, each protocol step is typically written in the form 
P — >■ Q : message 

This denotes that the principal P sends the message and that the principal Q receives 
it. The message is presented in an informal notation designed to suggest the bit-string 
that a concrete implementation would use. Unfortunately, this presentation is often 
ambiguous and obscure in its meaning, and is not an appropriate basis for formal 
analysis. 

Therefore, we transform each protocol step into an idealized form. A message in 
the idealized protocol is a formula. For instance, in the literature we may find the 
protocol step 

A ^ B : {A, K ab } Kb , 
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This may tell B } who knows the key Kb S} that K a b is a key to communicate with A. 
This step should then be idealized as 

When the message is sent to B } we may deduce that the formula 
B<{A*h b B} Kb . 

holds, indicating that the receiving principal becomes aware of the message and can 
act upon it. 

In this idealized form, we omit parts of the message that do not contribute to the 
beliefs of the recipient. In particular, we remove hints that are added to an implemen- 
tation to allow it to proceed in a timely fashion, but whose presence would not affect 
the result of the protocol if each host were to act spontaneously. For instance, we may 
omit a message used as a hint that communication is to be initiated. 

The idealized protocols of the examples given below do not include cleartext mes- 
sage parts; idealized messages are of the form {Xi}k\ , • • • , {X n }x n , where each en- 
crypted part is treated separately. We have omitted cleartext communication simply 
because it can be forged, and so its contribution to an authentication protocol is mostly 
one of providing hints as to what might be placed in encrypted messages. 

We view the idealized protocols as clearer and more complete specifications than 
the traditional descriptions found in the literature, which we view merely as implemen- 
tation-dependent encodings of the protocols. Therefore, we recommend the use of the 
idealized forms when generating and describing protocols. Though not entirely trivial, 
deriving a practical encoding from an idealized protocol is far less time consuming and 
error prone than understanding the meaning of a particular informal encoding. 

Nevertheless, in order to study protocols from the existing literature, we must first 
generate idealized forms for each protocol. In general, it is easy to generate a useful 
logical form for a protocol once it is intuitively understood. However, the idealized form 
of each message cannot be determined by looking merely at a single protocol step by 
itself. Only knowledge of the entire protocol can determine the essential logical contents 
of the message. There are guidelines to control what transformations are possible, and 
these help in determining the idealized form for a particular protocol step. Roughly, 
a real message m can be interpreted as a formula X if whenever the recipient gets m 
he may deduce that the sender must have believed X when he sent m. Real nonces 
are transformed into arbitrary new formulas; throughout, we assume that the sender 
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believes these formulas. The notation (X) Y , which denotes the use of Y as a secret, can 
be introduced only when the secret is intended as a proof of identity. Most important, 
for the sake of soundness, we always want to guarantee that each principal believes the 
formulas that he generates as messages. 

Protocol analysis 

From a practical viewpoint, the analysis of a protocol is performed as follows: 

• The idealized protocol is derived from the original one. 

• Assumptions about the initial state are written. 

• Logical formulas are attached to the statements of the protocol, as assertions about 
the state of the system after each statement. 

• The logical postulates are applied to the assumptions and the assertions, in order 
to discover the beliefs held by the parties in the protocol. 

This procedure may be repeated as new assumptions are found to be necessary 
and as the idealized protocol is refined. 

More precisely, we annotate idealized protocols with formulas and manipulate these 
formulas with the postulates. A protocol is a sequence of "send" statements Si, . . . , S n , 
each of the form P — >■ Q : X with P ^ Q. An annotation for a protocol consists of a 
sequence of assertions inserted before the first statement and after each statement; the 
assertions we use are conjunctions of formulas of the forms P ^ X and P<X. The first 
assertion contains the assumptions, while the last assertion contains the conclusions. 
Roughly, annotations can be understood as simple formulas in Hoare logic. We write 
them in the familiar form 

[assumptions] Si [assertion 1] ... [assertion n — 1] S n [conclusions] 

(In the examples below, however, we do not demonstrate the use of this notation, since 
we wish to concentrate on the assumptions and conclusions.) 

We want annotations to be valid in the following sense: if the assumptions hold 
initially, then each assertion holds after the execution of the protocol prefix that it 
follows. Clearly, validity is a semantic concept. Its syntactic counterpart is derivability; 
we give rules to derive legal annotations to protocols: 

• For single protocol steps: the annotation [Y] (P — >■ Q : X) [Y, Q < X] is legal. All 
formulas that hold before a message is sent still hold afterwards; the only new 
development is that the recipient sees the message. 
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• For sequences of protocol steps: if the annotations [-X"]Si . . . [Y] and [i^S^ . . . [Z] 
are legal then so is [X]Si . . . [X]^ • • • [Z]. Thus, annotations can be concatenated. 

• Logical postulates are used: 

o If X is an assertion (but not the assumptions) in a legal annotation A } if X' 
is provable from X, and if A' is the result of substituting X' for X in A, then 
A' is a legal annotation. Thus, new assertions can be derived from established 
ones. 

o If X is the assumptions of a legal annotation A, if X' is provable from X, 
and if A' is the result of substituting (X, X') for X in A, then A' is a legal 
annotation. Thus, the consequences of the original assumptions can be written 
down explicitly next to the original assumptions. 

A legal annotation of a protocol is much like a sequence of comments about the 
states of belief of principals in the course of authentication. Step by step, we can follow 
the evolution from the original assumptions to the conclusions — from the initial beliefs 
to the final ones. 

On time 

Note that our logic has not, and does not need, any notion of time to be associated 
with individual statements. The requirement to deal with time is entirely satisfied 
by the division of time into past and present, and by the semantics of the constructs 
themselves. This is possible because we found it sufficient to reason with stable for- 
mulas, that is, formulas that stay true for the whole run of the protocol once they 
become true. In addition, we represent protocols as sequential algorithms and ignore 
concurrency issues. As in the published protocols, a partial ordering of algorithmic 
steps is imposed by functional dependence. 

It was a conscious decision to avoid the explicit use of time in the logic presented, 
and we found it unnecessary for describing the protocols investigated so far. We feel 
that, though this approach might seem simple-minded, it has greatly increased the 
ease with which the logic can be manipulated. More ambitious proofs may require 
finer temporal distinctions, reflected by constructs to reason about additional epochs, 
or even general-purpose temporal operators (see, for example, Nguyen & Perry; Halpern 
& Vardi 1986). However, it is not clear that such proofs would offer greater insight into 
the workings of the protocols, nor be simple enough to construct without considerable 
expertise. 
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It should be noted that some authentication protocols make use of timestamps, 
but this does not require time to be made explicit in the logic. As for nonces in general, 
the only important property of timestamps is whether they are known to be fresh. 

3. The Goals of Authentication, Formalized 

Initial assumptions must invariably be made to guarantee the success of each protocol. 
Typically, the assumptions state what keys are initially shared between the principals, 
which principals have generated fresh nonces, and which principals are trusted in certain 
ways. In most cases, the assumptions are standard and obvious for the type of protocol 
being considered. Occasionally, however, analysis of a protocol suggests that further 
assumptions are made. Once all the assumptions have been written, the verification of 
a protocol amounts to proving that some formulas hold as conclusions. 

There is room for debate about what should be the goals of authentication pro- 
tocols that these conclusions describe. Often authentication is a precursor to some 
communication protected by a shared session key, so we might desire conclusions that 
describe the situation at the start of such a communication. Thus, we might deem that 
authentication is complete between A and B if there is a K such that: 

A |ee A&B 
B^A&B 

Some authentication protocols achieve more than this. In particular, many achieve, in 
addition: 

A |ee B |ee A&B 
B^A^A^B 

However, common belief in the goodness of K is never required — that is, A and B need 
not believe that they both believe that they both believe that . . . they both believe that 
K is good. Some protocols may attain only weaker goals, as for example A ^ B ^ X, 
for some X, which reflects only that A believes that B has recently sent messages and 
exists at present. 

Some public-key protocols are not intended to result in the exchange of a shared 
key, but instead transfer some other piece of data. For example, the interaction of a 
principal with the certification authority might be intended to transfer a single public 
key: 

A ^ 
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In addition, principals may establish some shared secrets: 
A |ee A^B 

In such cases, the required goals are generally obvious from the context. 

In the following sections, we examine a number of protocols and determine the 
nature of the guarantees they offer. 

4. The Otway-Rees Protocol 

Otway and Rees proposed a shared-key authentication protocol which involves two 
principals and an authentication server (1987). The protocol is attractive in that it 
provides good timeliness guarantees in a small number of messages. Moreover, it makes 
no use of synchronized clocks, and is easily implemented as two nested remote procedure 
calls. Although not widely used, it is a well designed protocol that may have application 
in certain environments. 

We give the protocol below, with A and B as the two principals, K as and K bs as 
their private keys, S as the authentication server. The principals A and B generate 
the nonces N a , N b} and M; the server S generates K ab , which becomes the session key 
between A and B. 

M, A, 5, j.V„. M, A, B} Ka . 
M, A, 5, j.V„. M, A, /iU... j.Y,,. M, A, B} Kb . 
M, {N a , K ab } Ka ,, {N b , K ab } Kb , 
M, {iV a , K ab } Ka , 



Message 1 A ->■ B: 

Message 2 B -> S: 

Message 3 S — >■ B: 

Message 4 B A: 



This message sequence is represented in the diagram below. 

A passes to B some encrypted material useful only to the server, together with 
enough information for B to make up a similar encrypted message. B forwards both 
to the server, who decrypts and checks whether the components M, A, and B match 
in the encrypted messages. If so, S generates K ab and embeds it in two encrypted 
messages, one for each participant, accompanied by the appropriate nonces. Both are 
sent to B } who forwards the appropriate part to A. Then A and B decrypt, check their 
nonces, and if satisfied proceed to use K ab . 
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3: M, j.V„. K ab } Ka „\\2: M, A, 5, j.V„. M, A, B} Ka , 
{N b , K ab } Kb , \\ {N b , M, A, B} Kbs 




1: M, A, 5, j.V„. M, A, B} Ka . 



4: M, {iV a , tf a6 }*r a . 




The Otway-Rees Protocol 



Now we transform the protocol. The nonce N c corresponds to M, A, B in the 
protocol description above. 



Message 1 A ->■ 5: 
Message 2 B ^ S: 
Message 3 5 — > -B: 



{iV a , JV c }* a . 

{iV a ,iV c } Ka3 , {iV 6 ,iV c }^. 



{iV a ,(A^5), (B^c)}*.. 



{iV 6 , (A^ 6 5), (A^iV c )} 



A", 



Message 4 B -+ A: {iV a , (A (5 ^ W c )}*r a , 



The idealized messages correspond quite closely to the messages described in the 
published protocol. We omit cleartext communication throughout, since it provides no 
guarantees of any kind. 

Further differences can be seen in the idealized forms of messages 3 and 4. The 
concrete protocol mentions the key K ab} which in this sequence has been replaced by 
the statement that A and B can use K ab to communicate. This interpretation of the 
messages is possible only because we know how the information in the messages should 
be understood. For example, when A receives N a and K ab} he can deduce that the 
key K ab is intended for use in talking to B } because the nonce N a appears both in this 
message and in A's request for such a key. 
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Even more interesting are the statements A |~ N c and B |~ N c . These do not 
appear to correspond to anything in the concrete protocol; they represent the fact that 
the messages are sent at all, because if the common nonces had not matched nothing 
would ever have happened. 

At this point, we can convince ourselves that the idealized protocol accurately 
represents the actual one and that the guidelines for constructing idealized protocols 
are not violated. 

The protocol analyzed 

To analyze this protocol, we first give the assumptions: 



The first group of four is about shared keys between the clients and the server. The 
fifth indicates that the server initially knows a key which is to become a shared secret 
between A and B. The next group of four indicates the trust that A and B have in 
the server to generate a good encryption key and to forward a message from the other 
client honestly. The final three assumptions show that three nonces have been invented 
by various principals who consider them to be fresh. 

Once we have the assumptions and the idealized version of the protocol, we can 
proceed to verify it. The rest of the procedure consists merely of applying the postulates 
of the logic and the annotation rules to the formulas available. It would be excessive 
to give the detailed deductions that we have checked mechanically — however, we would 
be happy to provide details of our formal proofs to readers interested in constructing 
their own. The proof may be briefly outlined as follows. 

A sends his message to B. Now B sees the message, but does not understand it: 



A |ee i nS 
S |ee A K A'S 

S |ee A } h b B 



B \eBV>'S 
S \eB*&S 



A |ee (S\^ A^B) 
A\=(S&(B\~X)) 



B |ee (S& A&B) 
B\=(S&(A\~X)) 



B<{N a ,N c } Ka 
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B is able to generate a message of the same form and to pass it on to S along with 
A's message. On receiving the message, S can decrypt each encrypted part according 
to the relevant message-meaning postulate, and so deduce that both A and B have 
encrypted the nonce N c in their messages: 



Note that S cannot tell whether this message is a replay or not, since there is nothing 
in the message that he knows to be fresh. S emits a message containing two encrypted 
messages to B. One of the parts is intended for A, and B passes it on. 

At this point, both A and B have received a message from the server containing 
a new encryption key and a nonce. We successively apply the postulates on message 
meaning, nonce verification, and jurisdiction, and emerge with the following final be- 



lt is interesting to note that this protocol does not make use of K a b as an encryption 
key, so neither principal can know whether the key is known to the other. A is in a 
slightly better position than B } in that A has been told that B emitted a message 
containing a nonce that A believes to be fresh. This allows A to infer that B has sent 
a message recently — B exists. B has been told by the server that A has used a nonce, 
but B has no idea whether this is a replay of an old message or not. 

In addition, we may notice that there are various forms of redundancy in the 
protocol. Two nonces are generated by A; however the verification using N a could just 
as well have been done using N c . Therefore, N a can be eliminated, so reducing the 
amount of encryption in the protocol. Moreover, it is clear from the analysis that iV& 
need not be encrypted in the second message. As these possibilities are explored, we 
rapidly move towards an improved protocol of different structure. 

5. The Needham-Schroeder Protocol (with shared keys) 

Many existing authentication protocols are derived from the Needham-Schroeder pro- 
tocol (1978). The original protocol is interesting, both because so much work has been 
based on it, and also because it has a serious weakness. 



S^A\^(N a ,N c ) 
S\BB\~(N b ,N c ) 



liefs: 



A |ee i A'B 

A |ee B \e N c 



B |ee A *$B 
B^A^N C 
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This protocol has the same cast of players as the Otway-Rees protocol. 



Messaj 


^e 1 


A - 


-> S: 


A, 5, iV a 


Messaj 


^ 2 


S - 


* A: 


{iV a , 5, K ab ,{K ab , A} Kbs } Ka 


Messaj 


r,e 3 


A - 


-> B : 


{K ab , A} Kbs 


Messaj 


;e 4 


B - 


-»■ A: 


{N b } Kab 


Messaj 


r,e 5 


A - 


-> 5: 


{N b - l} Kab 



Here only A makes contact with the server, who provides A with the session key, 
K ab} and a certificate encrypted with B } s key conveying the session key and A's identity 
to B. Then B decrypts this certificate and carries out a nonce handshake with A to be 
assured that A is present currently, since the certificate might have been a replay. The 
use of N b — 1 in the last message is conventional. Almost any function of N b would 
do, as long as B can distinguish his message from A's — thus, subtraction is used to 
indicate that the message is from A, rather than from B. 




The Needham-Schroeder Protocol (with shared keys) 



The idealized protocol is as follows: 

Message 2 S -+ A: {iV a , (A*h h B), ^(A^B), {A K A b B} Kb ,} Ka , 
Message 3 A -> B: {A K <$B} Kb , 



Message 4 B -> A: {N b , (A l^B)} Kab from B 
Message 5 A -> B: {N hl {A K ^B)} Kab from A 

The first message is omitted, since it does not contribute to the logical properties 
of the protocol. The result is as if S acted spontaneously. The last two messages of 
the idealized protocol are written in full, including the senders' names. This is merely 
to distinguish the two messages, which might otherwise be confused. In this case, the 
concrete realization of this distinction is, of course, the subtraction in the final message. 

The additional statements about the key K a b in messages 2, 4, and 5 are present 
to assure A that the key can be used as a nonce and to assure each principal that 
the other believes the key is good. These statements can be included because neither 
message would have been sent if the statements were not believed. 



The protocol analyzed 

To start, we give some assumptions: 



A\EA*h'S B\eB*&'S 

S^A^'S S^B K ^'S 
S |ee A } h b B 

A\e(S& A&B) B\e(S& A&B) 
A^(S^UA^B)) 

A N Wa) B |= $(N h ) 

S^^A^B) B^%(A^B) 



Most of the assumptions are routine. The first group of five describes the keys initially 
known to the principals. The next three indicate exactly what the clients trust the 
server to do. As before, S is trusted to make new keys for A and B } but here A also 
trusts S to generate a key which has the properties of a nonce. In fact, one can argue 
that a good encryption key is very likely to make a good nonce in any case. However, 

the need for this assumption has highlighted the need for this feature in the protocol. 

K 

The last assumption, B ^ §(A<-*B), is unusual. As discussed below, the protocol 
has been criticized for using this assumption, and the authors did not realize they were 
making it. The proof outlined here shows how this added assumption is needed to 
attain authentication. 
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Again the detail in the verification is suppressed. First, A sends a cleartext message 
containing a nonce. This can be seen by the server, who repeats the nonce in the reply. 
The reply from S also contains the new key to be used between A and B. Then A sees 
the entire message, 

A«{N a , (A K * b B), tt(A^B), {A K * b B} Kl .} K „ 

which he decrypts. Since A knows N a to be fresh, we can also apply the nonce- 
verification postulate, leading to: 

A |ee S \EA*h b B 
A |ee S |ee UA K ^ b B) 

The jurisdiction postulate enables us to infer: 

A |ee A } h b B 
A |ee %(A*h b B) 

Also, A has seen the part of the message encrypted under B } s private key, 
A<{A*h b B} Kb . 

This allows A to send this as a message to B. At this point, B decrypts the message, 
and from the appropriate message-meaning postulate, we obtain: 

B^S \~A*h b B 

Unlike A, however, B is unable to proceed unless we resort to the dubious assumption 
set out above. B knows of nothing in the message which is fresh, so he cannot tell 
when this message was generated. B simply assumes that the message from the server 
is fresh. 

If we make the necessary assumption, the rest of the protocol proceeds without 
any problem. We immediately obtain 

B |ee A*h b B 

via the postulates of nonce verification and jurisdiction. 

The last two messages cause A and B each to become convinced that the other 
exists (that is, he has sent messages recently) and is in possession of the key. B first 
encrypts his nonce and sends it to A, who can deduce that B believes in the key, 

A |ee B |ee A } h b B 
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because he has been guaranteed the freshness of the key by S. Then A replies similarly, 
and B can deduce that A also believes in the key, 



B |ee A |ee i 4 l B 



Note that the freshness of the nonce iV& is sufficient for B to deduce this. It is not 
necessary to reuse the dubious assumption. 

This results in the following beliefs: 



In fact, we could extend the idealized protocol, adding A ^ B ^ A <^ B to the last 
message, and obtain even 



This conclusion, however, seems to be of little importance for the subsequent use of 
the session key. 

This is a stronger outcome than in the Otway-Rees protocol, but it is reached at 
the cost of the extra assumption that B accepts the key as new. Denning and Sacco 
pointed out that compromise of a session key can have very bad results: an intruder has 
unlimited time to find an old session key and to reuse it as though it were fresh (1981). 
Bauer, Berson, and Feiertag pointed out that there are even more drastic consequences 
if A's private key is compromised: an intruder can use A's key to obtain session keys to 
talk to many other principals, and can continue to use these session keys even after A's 
key has been changed (1983). It is comforting that the logical analysis makes explicit 
the assumption. 

Clearly, the problem is that B has no interaction with S that starts with B } s 
initiative. It is possible to rectify this by starting with B rather than A, and this 
was done by Needham and Schroeder (1987). The note by Needham and Schroeder 
was published adjacent to the paper by Otway and Rees. Perhaps for the lack of 
a calculus to describe these protocols, none of the people involved realized that the 
proposals were essentially the same. The only significant difference is that the second 
Needham-Schroeder protocol goes on to use the session key (K a b) explicitly, thereby 
assuring each principal that the other knows the key, while Otway and Rees allow these 
final stages to be combined with the first transmissions of data. 



A |ee i A'B 

A |ee B |ee A } h b B 



B |ee i A'B 

B |ee A ^A } h b B 



B^A^B^ A A b B 
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A slight peculiarity in the original Needham-Schroeder protocol is that the cer- 
tificate {K a b } A} K b , is encrypted with A's key in the second message. Looking back 
through the formal analysis, one sees that this does not affect the properties of the 
protocol, since the certificate is sent to B immediately afterwards without further en- 
cryption. It may also be noticed that in message 4 a nonce is being sent encrypted 
when this is in general not necessary. However, in this instance, if the nonce were sent 
unencrypted it would be necessary to send something else encrypted in order for A to 
deduce that B knows the session key. 



6. The Kerberos Protocol 

The Kerberos protocol was developed as part of Project Athena at MIT (Miller et al. 
1987), and is now being used by a number of other organizations. It is based on the 
Needham-Schroeder protocol, but makes use of timestamps as nonces to remove the 
problems shown in the last section and to reduce the total number of messages required. 

A slightly simplified version of the protocol is shown below: 

A, B 

{T s , L, K ab , B, {T s , L, K ab , A} Kbe } Kae 
{T s , L, K ab , A} Kbs , {A, T a } Kab 
{T a + l} Kab 



Message 1 A — >■ S: 

Message 2 S -> A: 

Message 3 A -> B: 

Message 4 B ->■ A: 



Here, T s and T a are timestamps, and L is a lifetime. The protocol description 
states that the fourth message is used only if mutual authentication is required. 

We idealize the protocol as follows: 

Message 2 S ^ A: {T s , (A ^B), {T s , A K ^ b B} Kbe } Kat 
Message 3 A ^ B: {T s , a"U B} Kb „ {T a , a"U B} Kab from A 
Message 4 B -> A: {T a , A I h b B} Kab from B 



As in the Needham-Schroeder protocol, the first message is omitted, since it does 
not contribute to the logical properties of the protocol. For simplicity, the lifetime L 
has been combined with the timestamp T s , and is treated just like a nonce. 
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The Kerberos Protocol 

There is some potential for confusion between the second half of the third message 
and the last message. In the idealized protocol, we avoid this confusion by mentioning 
the originators explicitly. In the concrete protocol, either the mention of A in the third 
message or the addition in the fourth suffice to distinguish the two. There is no obvious 
reason for the use both features, though it seems likely that the second was inherited 
from the Needham-Schroeder protocol, in which a nonce is incremented in order to 
distinguish two messages that are otherwise identical. 



The protocol analyzed 

First we write the assumptions, which are quite standard: 

A\EA*h'S B^B^'S 

S^A^'S S^B^'S 
S |ee A } h b B 

A\e(S& A&B) B\e(S& A&B) 

A N KTs) B |= ft(T a ) 

It is clear from the last three assumptions that the protocol relies heavily on the use of 
synchronized clocks, since each principal believes that timestamps generated elsewhere 
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are fresh. 

The analysis is straightforward. A receives message 2, and from the rules of mes- 
sage meaning and nonce verification, we obtain: 

A |ee A } h b B 
A<{T s ,A I h h B} Kb , 

A passes on the encrypted message from the authentication server, together with 
another message containing a timestamp. Initially, B can decrypt only one part: 

B |ee A*h b B 

Knowledge of the new key allows B to decrypt the rest of the message; we thus obtain: 
B |ee A |ee A } h b B 

The fourth message simply assures A that B believes in the key, and received A's last 
message. The final result is: 

A\EA*h b B B\EA*h b B 
A\e B \e A*h b B B^A^A^B 

If only the first three messages are used, A ^ B ^ A^ b B is not generated. 
That is, the three-message protocol does not convince A of B } s existence. As with the 
Needham-Schroeder protocol, we can obtain 

A |ee B |ee A |ee A } h b B 

by adding B ^ A ^ A*¥± B to the fourth message of the idealized protocol. Again, 
this conclusion seems to be of little importance for the subsequent use of the session 
key. 

This result is similar to that for the Needham-Schroeder protocol. However, a 
major assumption in the Kerberos protocol is that the principals' clocks are synchro- 
nized with the server's clock. In practice, the effect of totally synchronized clocks is 
obtained by synchronizing clocks to within a few minutes with a secure time server, and 
detecting replays within the synchronization interval. However, actual implementations 
do not always include this check and so provide only weaker guarantees. Also, as in the 
Needham-Schroeder protocol, we can obtain the same final beliefs without the double 
encryption in message 2. 
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7. The Wide-mouthed-frog Protocol 



The following unpublished protocol was proposed by one of us (M.B.), and is perhaps 
the simplest protocol that uses shared-key cryptography and an authentication server. 
It transfers a key from A to B via S in only two messages by using synchronized clocks, 
and by allowing A to choose the session key: 

Message 1 A -> S: A, {T a , B } K ab } Ka . 
Message 2 S -> B: {T s , A, K ab } Kb , 




The Wide-mouthed-frog Protocol 



A sends a session key to S, including a timestamp T a . S checks that the first 
message is timely, and if it is, it forwards the message to B } together with its own 
timestamp T s . B then checks that the timestamp from S is later than any other it 
has received from S . Since all timestamps are either checked or generated by S, each 
principal need only record the difference between his own clock and S"s clock, updating 
it whenever clock drift causes an authentication message to be rejected. 

The idealized protocol is shown below: 

Message 1 A S: {T a , (A*h b B)} Ka . 
Message 2 S -»■ B: {T S} A ^ A R ^ b B} Kbs 
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The protocol analyzed 



The assumptions 3X6 3S follows: 



A |ee i nS 
S ^ 



5 

5 ^B^'S 



5 |ee (A^AAB) 



As in the Kerberos protocol, synchronized clocks are required. The more unusual 
assumptions are that A knows the session key in advance, and that B trusts A to 
invent good keys. 

The analysis is almost trivial. S receives the first message, and we deduce: 



S then sends the second message, which B receives and interprets. From the rules 
of message meaning, nonce verification, and jurisdiction, we obtain the final beliefs: 



The most dubious assumption in this protocol is that B trusts A to invent good 
keys. None of the protocols presented in this paper attempt to deal with malice on the 
part of one of the principals — either principal could simply reveal his keys to a third 
party. However, in this case, A is being trusted to be competent, rather than to be 
non-malicious. If the generation of session keys requires more care than A is expected 
to take, one might be unwilling to use this protocol. Of course, this assumption can 
be avoided, but only at the cost of an extra message, which allows B to pass on to A 
a session key invented by S. 

8. The Andrew Secure RPC Handshake 

An early version of the Andrew secure RPC protocol uses an authentication handshake 
between two principals whenever a client binds to a new server (Satyanarayanan 1987). 
The handshake is intended to allow a client, which we call A, to obtain a new session 
key K' ab from a server B } given that they already share a key, K a b- This protocol is 
vulnerable to an attack similar to that observed in the Needham-Schroeder protocol; 
it is no longer used. 



S |ee A \eA*$B 



A |ee i A'B 



B \eA *$B 

B |ee A |ee A K *$B 
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We discuss it here as an illustration of how easily such problems can be missed, 
and of how they manifest themselves in the logic. 



Message 1 A 

Message 2 B 

Message 3 A 

Message 4 B 



B: A, {N a } Kah 

A: {N a + 1, N h } Kah 

B: {N b + l} Kab 

A: {K' ab , N' h } Kab 



N a and N b are nonces; N' h is an initial sequence number to be used in subsequent 
communication. The first message simply transfers a nonce, which B returns in the 
second message. If A is satisfied with the reply, he returns B } s nonce. After B receives 
and checks the third message, he sends a new session key to A. As in the Kerberos 
protocol, nonces are returned incremented by one, even though there is no danger of 
generating identical messages during the protocol. 




The Andrew Secure RPC Handshake 



The idealized protocol closely resembles the real one: 

Message 1 A -> B: {N a } Kab 
Message 2 B -> A: {N a , N b } Kab 
Message 3 A -> B: {N b } Kab 

Message 4 B -> A: {A^B, N' h } Kab 
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The protocol analyzed 



First, we write the assumptions: 

A\e(B& A&B) B^A K X h B 
A |= l(N a ) B |= $(N h ) 

The first group of two indicates that A and B initially share a key. The next two show 
that B has invented a new key, and that A trusts B to invent good keys. Finally, each 
client is able to generate fresh nonces. 

We can now proceed with the analysis. The first message gives, simply: 

B^A^N a 
B«N a 

The second message contains a nonce that A believes is fresh, so we can deduce: 

A^B^(N a ,N b ) 
Hence, A knows that B exists. Similarly, the third message gives us: 

B |ee A \e N b 

B } now assured of A's existence, sends the new key, and we obtain the final beliefs: 

B |ee A K X h B 

A |ee B f~ (A K *k b B, Nl) 

B^A^N b 

A\EB\E(N a ,N b ) 

K' 

Unfortunately, we cannot proceed further. We cannot obtain 4 ^ B ^ i 4B 
because there is nothing in the fourth message that A believes to be fresh. We must 
conclude that the protocol suffers from the weakness that an intruder can replay an 
old message as the last message in the protocol, and convince A to use an old, possibly 
compromised session key. This problem is similar to that found in the Needham- 
Schroeder protocol. Fortunately, the problem can be fixed simply by adding the nonce 
N a to the last message: 

Message 4 B -+ A: {K' ab , N' h , N a } Kab 
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In fact, more substantial changes to the protocol can also reduce the total amount 
of encryption needed. The nonces are not used as secrets, and so need not be encrypted 
when first mentioned. Similarly, the starting sequence number N' b could just as easily 
be sent in clear, or identified with one of the other nonces. 

We arrive at a stronger protocol than the original one, but use less encryption. It 
suffices for B to send a key K' ab (along with a nonce N a ), 



B^A: {N a ,A K ^B} Kab 



In a concrete implementation, N a may be a timestamp or a nonce that A sent to B in 
a recent unencrypted message. A must reply with an acknowledgement that K' ab has 
been accepted, 



A^rB: {A K ^B} Kh 



B believes this message is timely because K' ab is fresh, B ^ ^ B). Optionally, B 
can go on to send an initial sequence number N' b in clear. 

If this new protocol is analyzed, we obtain the final beliefs: 



A\EA K *k b B B\eA*&B 
A^B^A^B B^A^A^B 

As a concrete realization of the protocol, we propose: 

Message 1 A -> B: A, N a 

Message 2 B -+ A: {N a , K' ab } Kab 

Message 3 A -> B: {N a }K' ab 

Message 4 B -> A: N' b 

In message 3, the use of N a is arbitrary; any predictable message will assure B that A 
has encrypted something with the new key. 
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9. The Yahalom Protocol 



The logic as we have described it serves in the analysis of a variety of protocols. On 
occasion, however, we have had to integrate new mechanisms for reasoning about some 
intriguing protocols. This section exemplifies how we adapt the logic, in this case to 
handle uncertified keys, and also illustrates the use of secrets. Once more, the logic 
guides us in understanding the operation of a protocol and in suggesting improvements 
to it. We consider the following ingenious protocol, due to Yahalom (personal commu- 
nication 1988). 

A, N a 

B, {A, N a , N b } Kbs 
{B } K ab , N a} N b } Ka „ {A, K ab } Kb . 
{A, K ah } Kb „ {N b } Kab 



Message 1 A ->■ B: 

Message 2 B -> S: 

Message 3 S — >■ A: 

Message 4 A ->■ B: 




The Yahalom Protocol 



The cast is the usual one. The novelty here is that the unusual sequence of messages 
results in strong guarantees for both A and B with few messages: A sends a nonce N a 
to S, indirectly, then gets it back with the key K ab} and B sends a nonce N b to S, then 
gets it back with the key K ab} indirectly. 
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As the idealized version of this protocol, we propose: 



Message 2 B -> S: {N a , N b } Kb , 

Message 3 S A: {A*h b B, ^(a'Ub), N a} N b} B f~ N a } Ka „ 

{A K * b B} KlM 

Message 4 A ^ B: {A K A b B} Kb „ {(N b} A*h b B, S \e %(A ~ b B)) Nb } Kab 

The first message is omitted, since it does not affect the logical analysis. The 
result is as if B acted spontaneously. In the third and fourth messages it is necessary 
to make explicit that the server asserts that the key K ab is fresh; this does not alter the 
essence of the protocol in any significant way — a good key should probably share the 
properties of a nonce. An unusual feature of the protocol is the use of N b as a shared 
secret in the fourth message. 



The protocol analyzed 

Most of the initial assumptions here are the same as for the Otway-Rees and 
Needham-Schroeder protocols: 

A^A } h'S B\eB*&S 

S^A^'S S\eB*&'S 
S |ee A K *$B 

A\e(S& A&B) B\e(S& A&B) 

A |= l(N a ) B |= l(N b ) 

However, several additional assumptions are also made in this protocol: 

S |ee UA R ^ b B) 

B^(S^UA^B)) 

B\e(A&S\e$(A&B)) 

A\e(S& B\~ N) 
B^A^B 

The first three additional assumptions are needed because B must know that the session 
key is fresh in order to deduce the timeliness of the fourth message. The next represents 
A's trust in S to pass on a nonce from B. The last assumption is interesting in that it 
was surprising to the author of the protocol. The protocol actually uses N b as a shared 
secret, although it was thought of simply as a nonce when the protocol was designed. 
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The second message produces: 



S \b B \~ (N a , N b ) 

From the third message, using the message-meaning, nonce- verification, and juris- 
diction rules, we derive: 

A<N b 

A |ee A } h b B 

A |ee S ^ ${A*&B) 

A^B^N a 

The fourth message is more complicated. We obtain: 

B ^S^A } h b B 
B<A*h b B 

However, we cannot proceed further. The protocol leads B to use the key K ab 
before ascertaining that it is a good key. That it is a good key is confirmed only after 
its first use, with the second part of the fourth message. We discuss below how we 
extend the logic to handle uncertified keys. For now, we proceed as if we could derive: 

B<(N b ,A*h b B, S^UA R ~ b B)) Nb 

Notice that use of the uncertified key allows B to see the contents of the message, but 
not to deduce the sender. Since B believes N b to be both a secret and fresh, we have: 

B |ee A |ee (A*h b B, S |ee B)) 

B trusts both S and A in statements about the freshness of the key, so: 

B |ee UA K ^ b B) 

This allows us to perform nonce verification on the other part of the message, 
leading eventually to: 

B |ee A } h b B 

So the final beliefs are: 

A^A } h b B B^A } h b B 
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A^B^N a B^A^Al^B 



The session key has been distributed, and each principal is aware that the other exists. 

The analysis shows two interesting points: N b is used as a shared secret, and B 
trusts A to pass on a statement about the freshness of the key. If A chose to replay 
an old key to B in message 4, B could not detect the fraud. This does not represent a 
major flaw in the protocol, since the principals are assumed not to be malicious, but 
merely highlights an assumption that was not clear at first. 

A simple change to the protocol removes these features, strengthening the protocol 
and simplifying the analysis at the same time. The concrete protocol becomes: 

A, N a 

B, N b , {A, N a } Kbs 

N b} {B } K ab , N a } Ka „ {A, K ab , N b } Kb . 
{A,K ab ,N b } Kb .,{Nb} Kab 

In the analysis of this variant, there is no need to use an uncertified key, because 
the timeliness of the last message is guaranteed by the nonce N b . Moreover, N b no 
longer need be kept secret, so it need not be encrypted in message 2 and the first half 
of message 3. The resulting protocol has the same outcome, but with less encryption 
and considerably fewer assumptions. 

On using uncertified keys 

As was discovered above, the logic presented so far does not provide any mechanism 
for decryption with keys that are not known to be good. Formally, the message-meaning 
rules and the rules for < apply only to keys believed good for some specified principal. 

Fortunately, it is straightforward to modify the logic and remedy this situation. It 
suffices to make the rules for < more liberal; concretely, we may supplement the rule 

P^Q^P, P<{X} K 
P<X 

with the rule 

P\eR\~Q&P, P<{X} K 
P«X 



Message 1 A ->■ B: 

Message 2 B -> S: 

Message 3 S — >■ A: 

Message 4 A ->■ B: 
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Intuitively, this new rule reflects the fact that P may try any key mentioned to him. 
The proposed solution handles this particular protocol, but it fails to handle other more 
intricate protocols. In fact, there seems to be no natural place to stop in making the 
logic stronger and stronger in this sense, by changing the rules for <. 

A more thorough solution requires a fairly serious change in the logic, which we 
describe briefly. Protocol descriptions can be changed to include not only a sequence of 
message exchanges but explicit statements for decryption. It becomes the responsibility 
of the protocol writer to say which keys should be tried for decryptions. The rules for 
annotations would then be extended, to say that the decrypter sees the inside of the 
messages he decrypts. The additional complexity of this solution seems unnecessary, 
since none of the published protocols we have encountered requires it. 

10. The Needham-Schroeder Public-Key Protocol 

In their original paper, Needham and Schroeder also proposed a protocol based on 
public-key cryptography (1978). This protocol allows two principals to exchange two 
independent, secret numbers. This is unlike most other public-key protocols, which 
allow the principals to exchange a shared session key. A weakness in the protocol 
allows a replay attack in the interactions with the certification authority if a key is 
compromised, much as in the Needham-Schroeder protocol discussed in section 5. 

The cast remains the usual one, but S operates only as a certification authority; 
K a , Kb, and K s are the public keys of A, B, and S, respectively; A'" 1 is the secret key 
that matches K s ; finally, N a and iV& are nonce identifiers. 

The message exchange goes as follows: 



Messaj 


^e 1 


A - 


-> S: 


A, B 


Messaj 


^ 2 


S - 


* A: 


{Kb, B} K -i 


Messaj 


re 3 


A - 


-> B : 


{Na, A} Kb 


Messaj 


re 4 


B - 


-> S: 


B } A 


Messaj 


re 5 


S - 


-> B : 


{K a ,A} K -i 


Messaj 


re 6 


B - 


-»■ A: 


{Na, N b } Ka 


Messaj 


re 7 


A - 


-> B : 


{N b } Kb 
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The Needham-Schroeder Public-Key Protocol 



The protocol has two rather independent but interleaved components. It is ex- 
pected that, initially, both A and B hold S"s public key K s . Therefore, the principals 
A and B can obtain each other's public keys from S . Messages 1, 2, 4, and 5 accomplish 
this purpose. In a second component, in messages 3, 6, and 7, A and B use the public 
keys obtained. They communicate the secret nonce identifiers N a and iV&. These secrets 
can be used later, for signing further messages. For example, if B receives a message 
{X, iV a }/f 6 , then B may deduce that A sent X. 

The idealized protocol is as follows: 



Messaj 


^ 2 


S - 


■* A: 




Messaj 


re 3 


A - 


-> B : 


{Na}K b 


Messaj 


$e 5 


S - 


-> B : 


{&A} K -i 


Messaj 


$e 6 


B - 


-»■ A: 


{(A^B) N J Ka 


Messaj 


^e 7 


A - 


-> B : 


{{A?*B,B\=(A*B)) Ni } 



Messages 1 and 4 are deliberately omitted, since they do not contribute to the logical 
properties of the protocol. The idealized protocol proceeds as if S contacted A and B 
spontaneously. 
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Messages 2 and 5 are straightforward, but the others require some explanation. 
It is interesting to note the difference between message 3 and messages 6 and 7. In 
message 3, N a is not known to B } and so is not being used to prove the identity of A; 
message 3 is used simply to convey N a to B. In messages 6 and 7, N a and iV& are used 
as secrets, so the (X) Y notation is used. These messages also convey beliefs that have 
no representation in the concrete protocol, because the messages would not be sent if 
the beliefs were not held. 

The protocol analyzed 

First we state the assumed initial beliefs of the players: 



AW 


hA 


BW 


\-^B 


AW 




BW 


K. Q 


s W 


hA 


SW 




s W 


K. Q 






AW 


(S\=> &B) 


BW 




AW 


UNa) 


BW 




AW 


A^B 


BW 


A^B 


AW 




BW 


K^A) 



Each principal knows the public key of the certification agent S, as well as his own keys. 
In addition, S knows his own keys, and the public keys of A and B. Each principal 
trusts the certification agent to correctly sign certificates giving the public key of the 
other. Also, each principal believes that the identifier that he generates is fresh, and 
secret. 

The last two assumptions are surprising, and they represent a weakness in the 
protocol. Each principal must assume that the message containing the public key of 
the other principal is fresh. The difficulty could be resolved by adding timestamps to 
messages 2 and 5. This is analogous to the way that Kerberos' timestamps overcome 
the problem with the shared-key Needham-Schroeder protocol. 

Once the assumptions are made, we apply the rules of message meaning and ju- 
risdiction to message 2, to deduce: 

A W ^B 
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B can deduce little from message 3, since he cannot know who sent the message. We 
obtain simply: 



B<N, 



a 



Message 5 is similar to message 2, giving: 



B |ee i^A 



In message 6, B uses the shared secret N a to convince A that the message is from B } 
and that the message is timely, giving: 



A is now able to use iV& in message 7. By the arrival of this message, B can deduce A's 
current beliefs about the state of the protocol, even though they have no representation 
in the concrete protocol. Thus, the final beliefs are: 



Each principal knows the public key of the other, and has knowledge of a shared secret 
which he believes the other will accept as being shared only by the two principals. B 
has gained slightly more knowledge through being the last recipient of a message in the 
protocol. From this point, A and B can continue to exchange messages using N a , iVj, 
and public-key encryption. In this way they can transfer data or other keys securely. 

Again, we could extend the idealized protocol, adding h-$A and k->5, B ^ h-$A 
to messages 6 and 7, respectively. We would then obtain 



A\eB\eA^B 



A ^ &B 
A^B^A^B 



B |ee £$A 

B |ee A |ee A^B 

B^A^B^A^B 



A |ee B |ee Z$A 



B^A^ f^B 
B\eA\eB\e&A 



These beliefs have no importance for subsequent communication. 
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11. The CCITT X.509 Protocol 



A draft recommendation for the CCITT X.509 standard contains a set of three protocols 
using between one and three messages (Comite Consultatif International Telegraphique 
et Telephonique (CCITT) 1987). It is our understanding that this has now become an 
official recommendation of the CCITT. The protocols are intended for signed, secure 
communication between two principals, assuming that each knows the public key of the 
other. The three-message version is given below. The two-message and one-message 
protocols are formed by removing the last one or two messages respectively. 

Unfortunately, the published protocol contains two weaknesses, either of which 
can be exploited by an intruder, as we shall demonstrate below. We found one of these 
weaknesses while idealizing the protocol and the other during the subsequent analysis. 
The protocol shown here has been simplified slightly, in a way which is discussed later. 



Message 1 A -+ B: A, {T a , N a , B, X a , {Y a } Kb } K -i 
Message 2 B ^ A: B, {T 6 , N b , A, N a , X b , {Y b } Ka } K -i 

b 

Message 3 A -> B: A, {N b } K -i 



1: A, {T a ,N a ,B, X a ,{Y a } Kb } K -i 
2: B, {T 6 , N b , A, N a , X b , {Y h } Ka } K -, 



3: A, {N b } K -i 



The CCITT X.509 Protocol 



Here, T a and T b are timestamps, N a and N b are nonces, and X a , Y a} X b} and Y b 
are user data. The protocol ensures the integrity of X a and X b} assuring the recipient 
of their origin, and guarantees the privacy of Y a and Y b . 

The idealized protocol is as follows: 
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Message 1 A -+ B: {T a , N a , X a , {Y a } Kb } K -i 
Message 2 B ^ A: {T 6 , N b , N a , X b , {Y b } Ka } K -, 

b 

Message 3 A -> B: {N b } K -i 

As usual, the timestamps T a and T b are viewed simply as nonces in the idealized 
protocol. 

The protocol analyzed 

We assume that each principal knows his own secret key, the other's public key, 
and believes his own nonce and the other's timestamp to be fresh. 

A\e&A B\e&B 
A\e&B B^hA 

A |= l(N a ) B |= $(N h ) 

A^UTb) B^UTa) 

From message 1, via the message-meaning rules, we obtain: 

B^A^X a 

B«Y a 

Using T a for nonce verification, we also derive: 
B^A^X a 

Note that B ^ A ^ Y a is not derivable. Message 2 produces: 
A<Y b 

Using T b or N a for nonce verification, we obtain: 
A |ee B \e X b 

Once again, we cannot obtain A ^ B ^ Y b . Message 3 gives: 
B |ee A ^ N b 
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That is, it assures B that A has recently sent N b . 

This represents an outcome weaker than the authors desired. Surprisingly, the 
protocol does not lead to B ^ A ^ Y a or A ^ B ^ Y b . Although Y a and Y b have each 
been transferred in a signed message, there is no evidence to suggest that the sender 
is actually aware of the data that he sent in the private part of the message. This 
corresponds to a scenario where some third party intercepts a message and removes 
the existing signature while adding his own, blindly copying the encrypted section 
within the signed message. This problem can be fixed by several means, the simplest 
of which is to sign the secret data Y a and Y b before it is encrypted for privacy. 

Some redundancy is noticeable in the second message; either T b or N a is sufficient to 
ensure the timeliness of the message. The protocol description states that the checking 
of T b is optional in the three-message version of the protocol. In fact, it is perfectly 
reasonable to omit T b altogether, since it is redundant in both the two and three- 
message protocols. 

Unfortunately, the document also suggests that T a need not be checked in the 
three-message protocol. This is a serious problem because the checking of T a is the 
only mechanism that establishes the timeliness of the first message. Logically, if T a is 
not checked, we cannot perform nonce verification on the first message, and we obtain 
only B |ee A f~ X a instead of B |ee A |ee X a . 

This difficulty explains the intention of the third message, which is to assure B 
that A generated his first message recently. The authors seem to have hoped that the 
use of N b would be sufficient to link the third message to the first, since N b links the 
last two messages and N a links the first two messages. The error here is that N b alone 
does not link the last two messages, and this allows an intruder C to replay one of A's 
old messages. 

The following concrete exchange illustrates the flaw. The nonce N b is not secret, 
and there is nothing to prevent C from using the same value in an instance of the 
protocol between A and C . If C is able to cause A to attempt authentication with C 
at the required time, the following sequence of messages can result. The intruder first 
contacts B: 

C^B: A, {T a , N a , B, X a , {Y a } Kb } K -i 

This is an old message originally sent by A. Remember that B is not presumed to check 
the timestamp T a in the three-message protocol, and so will not discover the replay of 
A's original message. 

B^C: B, {T b , N b , A, N a , X b , {Y b } Ka } K -i 
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B replies as though the message came from A, and provides a new nonce, N b . At this 
point C causes A to initiate authentication with C, by whatever means. 

A - C: A, {T' al N' a} C, X' a} {Y^} Kc } K -, 

A has now initiated authentication with C . The exact content of the message is im- 
material. C replies to A, providing the nonce iVj, which was originally provided by 
B. 

C^A: C, {T c , N b , A, N' a , X c , {Y c } Ka } K -i 

A replies to C, signing the exact message needed for C to convince B that the first 
message was sent recently by A, and is not a replay of an old message. 

A ^ C: A, {N b } K -i 

One possible solution is to include B } s name in the last message. Since B guar- 
antees the uniqueness of his own nonces, he can be sure that this message is linked 
uniquely to this instance of the protocol in a timely fashion. The idealized version of 
message 3 could then include any beliefs transmitted in message 1, assuring B of their 
timeliness. 

The X.509 protocol actually uses hashing to reduce the amount of encryption, 
though this has not been shown in the description above. The analysis of the protocol 
is changed only slightly by the introduction of hashing. The next section deals with 
hash functions and how their use can be modelled in the logic. 

12. On Hashing 

In practice, signatures are costly. Often, principals do not sign whole messages, mainly 
for reasons of efficiency. Rather, in order to sign a (long, mostly cleartext) message m, a 
hash H(m) of m is computed and signed. Thus, a principal A may send m, {H(m)} K -i 
instead of {m} K -i . It remains to understand how this scheme compares with straight- 
forward signature methods qualitatively: what guarantees do hash functions offer? 

Obviously, trust in protocols that use hash functions is not always warranted. If H 
is an arbitrary function, nothing convinces one that when A has uttered H(m) he must 
have also uttered m. In fact, A may never have seen m. This may happen, for instance, 
if the author of m gave H(m) to A, who signed it and sent it. This is similar to the way 
in which a manager signs a document presented by a subordinate without reading the 
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details of the document. However, the manager expects anyone receiving this signed 
document to behave as though the manager had full knowledge of the contents. Thus, 
provided the manager is not careless and the hash function is suitable, signing a hash 
value should be considered the same as signing the entire message. 

Some assumptions underlie the use of hash functions in signatures. As a basic 
assumption, it is intended that, given a hash value, it should be computationally in- 
feasible to put together a message with the same hash value. Moreover, it should be 
computationally infeasible to generate two messages giving the same hash value, to 
avoid uncertainty in the identity of the data being signed. 

We wish to capture the reasoning implicit in the use of hash functions. We intro- 
duce a symbol H to represent each function of interest. A postulate to attribute the 
message m to the author of the message H(m) is wanted. 

For a hash function H , we postulate: 

P\eQ\~H{X), P«X 

In fact a stronger postulate appears reasonable, in the case where a message has 
been broken up into lots of pieces. This case in fact arises in such proposed standards 
as CCITT's X.509 (1987): 

P\EQ\~H(X 1 ,...,X k ), P<X 1 ,...,P<X k 
P^Q] r (X 1 ,...,X k ) 

The significance of this postulate is that a principal may see pieces of a composite 
message by different means; in particular, some pieces may be the results of decryption. 
The principal may indeed come by the various pieces at different times — it makes no 
difference. When a signed hash of the composite message is received, it is still possible 
to deduce the origin of the composite message. 

13. Semantics 

Hopefully, the formulas liberally sprinkled throughout this paper are intuitively clear. 
In this section we take a more formal approach than previously and discuss a formal 
semantics of these formulas. 
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Beliefs 



We describe an "operational" semantics, according to which principals develop beliefs 
by computation. In order to obtain new beliefs, principals are supposed to examine 
their current beliefs and apply a few computationally tractable inference rules. These 
rules represent the idealized workings of principals in actual authentication protocols. 
Thus, the statement that an authentication protocol gives rise to certain beliefs is 
a strong one: it means that the principals develop these beliefs even with realistic 
computational resources. However, the restrictive, operational notion of belief that we 
have adopted would certainly be harmful in the study of security properties, where we 
would want to guarantee that intruders learn no secrets even with powerful methods 
or algorithms. 

The local state of a principal P is two sets of formulas Aip and Bp. Intuitively, 
Aip is the set of messages that the principal sees and Bp is the set of beliefs of the 
principal. The sets Aip and Bp enjoy some closure properties; for simplicity, we take 
closure properties that correspond directly to the inference rules of the logic. For 
instance, 

if (P&Q) £ Bp and {X} K eM P then X £ M P . 

We imagine the closure properties are enforced by algorithms to derive and add new 
messages and beliefs. 

A global state is a tuple containing the local states of all principals; in all the cases 
we consider, it is a triple with the local states of A, B } and S. If s is a global state 
then sp is the local state of P in s and Bp{s) and Ai p{s) are the corresponding sets 
of beliefs and messages. The satisfaction relation between global states and formulas 
has a trivial definition: P ^ X holds in state s if X £ Bp(s) } and P < X holds if 
X £ Aip(s). A set (or conjunction) of formulas holds in a given state if each of its 
members holds. 

A run is a finite sequence of states so,...,s n where Bp(si) C Bp(si+\) and 
■Mp(si) C Aip(si+i) for all i < (n — 1) and for each principal P. In other words, 
the sets of messages seen and the sets of beliefs can only increase. A run is a run of a 
particular protocol if all of the messages the protocol prescribes are communicated — 
other messages may be initially present or may come from the environment. More 
precisely, a protocol is a finite sequence of n "send" statements of the form 

(Pi — >■ Qi : Xl), . . . , (P n — >■ Q n : X n ) 
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A run of the protocol is a run of length n + 1 where Xi £ AiQ { (si) for all i < n. 

An annotation for the protocol holds in a run of the protocol if all of the formulas 
in the annotation hold in the corresponding states. More precisely, an annotation 
consists of n + 1 sets of formulas of the forms P ^ X and P <\ X inserted before and 
after statements; it holds in a run of the protocol if the z'-th set holds in the z'-th state 
of the run for all i < n. An annotation is valid if it holds in all runs of the protocol 
where the first set of the annotation — the assumptions — holds. 

Immediately, the annotation rules described earlier are sound: all legal annotations 
are valid. Just as trivially, the rules are also complete: all valid annotations are legal. 
To see this, given a protocol (Pi — > Q\ : Xi),...,(P n — > Q n : X n ) consider a run 
so, . . . ,s n where only the messages X\ , . . . , X n are communicated. All valid annotations 
must hold in this run. Furthermore, we can show that any annotation that holds in 
this run can be derived. 

True beliefs 

While the semantics gives a meaning to the operators ^ and <, the remaining operators 
are still largely a mystery. For instance, the semantics does not determine whether 
A |~ N a is true or false in a given state. This is a deficiency if we are interested in 
judging the truth of beliefs. 

Conjunction and quantification receive their usual interpretation (for quantifica- 
tion, we assume that the variables range over given domains of principals, keys, and 
formulas). In order to give a meaning to the remaining operators, however, the notion 
of state needs to be richer than the one we have used so far, as follows: 

• Each state associates with each principal P a set Op of formulas that he once said. 
This set has three closure properties: if ({X}k from P) £ Op then X £ Op; if 
(X) Y £ Op then X £ O p ; if (X,Y) £ O p then X £ O p . We require that if 
Pi Qi '■ Xi is the z'-th action of a protocol then the set of formulas once said 
increases only for Pi in the z'-th state of all runs of this protocol. More precisely, if 
R ^ Pi then OR(si) = (9^(^-1 ) and Op { (si) is the closure (by the rules above) of 
Op { (si-i) U {A^}. In addition, each principal must believe all the formulas he has 
said recently, in the sense that if X £ Op{s) because of a message in the protocol 
then X £ Bp(s). 

The formula P |~ X holds in state s if X £ Op{s). 

• In each run each principal P has jurisdiction over a set of formulas Jp. We require 
that if X £ Jp and P ^ X holds then X holds as well. 
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The states in the run satisfy P |=> X if X £ J P . 

• Each run assigns a set of good shared keys £{p,q} to each pair of principals P 
and Q. We require that these keys are used only by the appropriate principals, 
that is, if R < ({X}k from R') holds and K £ £{p,q} then either R' = P and 
{{X} K from P) £ Op or R' = Q and ({X} K from Q) £ Oq. 

K 

The states in the run satisfy P if K £ /C{pq}. 

• Each run assigns a set of good public keys ICp to each principal P. We re- 
quire that only the appropriate principals use the matching secret keys, that is, if 
R < ({X} K -ifrom R r ) holds and K £ K P then R' = P and ({X} K -ifrom P) £ O p . 

K 

The states in the run satisfy i— >P if K £ ICp. 

• Each run assigns a set of shared secrets <5{p ; Q} to each pair of principals P and Q. 
We require that shared secrets are used only by the appropriate principals, that 
is, if R <l (X) Y holds and Y £ <5{p ; Q} then either (X) Y £ Op or (X) Y £ Oq. 

The states in the run satisfy P if X £ <S{pq}. 

• Since we do not concern ourselves with expressions of the forms P ^ {X}k and 
P ^ (X) Y , we do not even attempt to assign a truth value to expressions of the 
forms {X}k or (X) Y - 

• Each run determines a set of fresh formulas T . This set has a closure property: if 
X £ T and X is a subformula of Y then Y £ T . If X £ J 7 and X was once said 
(that is, X £ (9p(si) for some P and z) then X should have been said recently 
(that is, X £" Op(s 0 ) for all P). 

The states in the run satisfy $(X) if X £ J 7 . 

Clearly, some beliefs are false. This seems essential to a satisfactory semantics. 
Questions of trust and delegation, central to our study, would become meaningless 
if all beliefs had to be true. Moreover, we can consider many interesting runs — for 
instance, those where an intruder has broken the cryptosystem — because we leave open 
the possibility of incorrect beliefs. 

Let us define knowledge as "truth in all possible worlds" (see, for example, Halpern 
& Moses 1984). More precisely, P knows X in state s if and only if X holds in all states 
s' where the local state of P is the same as in s, that is, s' p = sp. In general, the notions 
of knowledge and belief are incomparable. For instance, some erroneous initial beliefs 
are certainly not knowledge, while each principal knows all tautologies, but does not 
necessarily believe them. 
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Most beliefs happen to be true in practice, but the semantics does not account 
for this coincidence. To guarantee that all beliefs are true we would need to guarantee 
that all initial beliefs are true. In this case, belief is a rudimentary resource-bounded 
approximation to knowledge. 

14. Conclusions 

Recent literature has emphasized the importance of reasoning about knowledge for 
understanding distributed computation (see, for example, Halpern & Moses 1984). Fur- 
thermore, there have been some formal descriptions of cryptographic protocols (DeMillo 
et al. 1982; Merritt & Wolper; Halpern et al. 1988). Although these works have not 
suggested useful proof systems, they could serve as a foundation for our more specific 
analysis of authentication protocols. 

In this paper we have described a logic to reason about authentication protocols 
and we have treated several examples. The following table lists protocols studied with 
the logic and summarizes their attributes. 





Needham- 
Schroeder 
conv. key 


Otway- 
Rees 


Kerberos 


Wide- 
mouthed- 
frog 


Yahalom 


Andrew 
RPC 


Needham- 
Schroeder 
public key 


CCITT 
X.509 


Goal 


distribute 
key 


distribute 
key 


distribute 
key 


distribute 
key* 


distribute 
key 


distribute 
extra key 


establish 
secrets 


transfer 
data 


Cryptosystem 


conv. 


conv. 


conv. 


conv. 


conv. 


conv. 


public key 


public key 


Uses secrets 










X 




X 




Nonces/clocks 


nonces 


nonces 


clocks 


clocks 


nonces 


nonces 


nonces 


both 


Proves 
presence of 




B 




A 










Redundancy 


X 


X 


X 




X 


X 




X 


Bugs 


X 










X 


X 





* In this case, A, rather than a trusted server, generates the key. 

f B's presence is guaranteed to A only if optional protocol steps are used. 

% Security breaches do not even require key compromise. 



The table shows some well-known properties: 
the goal of each protocol, 

the type of cryptosystem used, shared key or public key, 
whether secrets (other than keys) are used, and 

whether message timeliness is guaranteed with nonces or synchronized clocks. 
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In addition, we include aspects that our formalism helped bring to light: 
whether the protocol proves the presence of each party to the other, 
redundancy, and 
security problems. 

The principals involved in the protocols are A and B; the initiator is A. 

The examples in this study show how an extremely simple logic can capture subtle 
differences between protocols. The logic lacks all features that would make it difficult 
to use, yet it does what is needed. For a variety of protocols, it enables us to exhibit 
step by step how beliefs are built up to the point of mutual authentication. For other 
protocols, it guides us in identifying mistakes and suggesting corrections. 
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